Thank you. We are still seeing the bug [1] regularly, so +1 on merging this.

[1] https://bugs.chromium.org/p/oss-fuzz/issues/list?q=bitcoin-core%20float%20%20ASSERT%20encoded_in_memory&can=1

Let me know if I should manually test this on bitcoin-core, or if it is good to go in as-is.

@oliverchang @jonathanmetzman Anything needed to do here?

CI failure is not mine:

=================================== FAILURES ===================================
_________________ GenerateImplTest.test_generate_swift_project _________________
[gw1] linux -- Python 3.8.12 /opt/hostedtoolcache/Python/3.8.12/x64/bin/python

self = <helper_test.GenerateImplTest testMethod=test_generate_swift_project>

    def test_generate_swift_project(self):
      """Tests that the swift project uses the correct base image."""
      helper._generate_impl(helper.Project(self.PROJECT_NAME), 'swift')
>     self._verify_templated_files(
          templates.TEMPLATES,
          os.path.join(helper.OSS_FUZZ_DIR, 'projects', self.PROJECT_NAME),
          'swift')

infra/helper_test.py:156: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
infra/helper_test.py:129: in _verify_templated_files
    self.assertEqual(contents, template % template_args)
E   AssertionError: '#!/b[23 chars]t 2022 Google LLC\n#\n# Licensed under the Apa[869 chars].a\n' != '#!/b[23 chars]t 2021 Google LLC\n#\n# Licensed under the Apa[869 chars].a\n'
E   Diff is 1041 characters long. Set self.maxDiff to None to see it.
=========================== short test summary info ============================
FAILED infra/helper_test.py::GenerateImplTest::test_generate_swift_project - ...
============= 1 failed, 223 passed, 8 skipped in 404.07s (0:06:44) =============

@jonathanmetzman Let's get ready to try this this week? I also have google/clusterfuzz#2520 out to give us an extra day to revert if something goes wrong.

this is now open for 4 weeks ... @jonathanmetzman @DavidKorczynski @inferno-chromium

step 1: geht this merged and see if anything still fails
step 2: update llvm and see if anything new fails

this is now open for 4 weeks ... @jonathanmetzman @DavidKorczynski @inferno-chromium

step 1: geht this merged and see if anything still fails step 2: update llvm and see if anything new fails

My position remains as above: #7026 (review) - this lgtm (and thanks for fixing it up!!) and will wait for others to merge in

@jonathanmetzman - i am merging this since some folks have tested this. please keep an eye.

Thanks for merging. I'll let you know if I notice anything strange in Qt.

Let's wait a day before rolling clang.

By my count, this causes the following breakages:
cpython3: FATAL: forkserver is already up, but an instrumented dlopen() library loaded afterwards. You must AFL_PRELOAD such libraries to be able to fuzz them or LD_PRELOAD to run outside of afl-fuzz.
libxml Null deref at runtime (genSeed)
mercurial: FATAL: forkserver is already up, but an instrumented dlopen() library loaded afterwards. You must AFL_PRELOAD such libraries to be able to fuzz them or LD_PRELOAD to run outside of afl-fuzz.

mercurial and cpython3 fail and it is good that they fail as this is a bad setup (that is why the behaviour changed. before it was silently just being less effective). there is an env to ignore this, but rather the setup should be fixed. I can help the devs to get this working. I can also set that env var that keeps ignoring it though.

libxml - I will take a look.